% ----------------------------------------------------------------------- %
% Arquivo: nsis.tex - CAPITULO 3
% ----------------------------------------------------------------------- %

\chapter{O protocolo NSIS}
\label{c_cap3}

Conforme apresentado no capítulo anterior, os protocolos de
sinalização são fundamentais para a operacionalização de um modelo de
\ac{QoS}. Com fins de criar um protocolo de sinalização para atender os
requisitos
das redes de próxima geração, a \ac{IETF} criou o grupo de trabalho do \ac{NSIS}
(\textit{Next Steps in Signaling}) que resultou em uma série de \ac{RFC} e
\textit{drafts} até o presente momento.
 
\section{Visão Geral do projeto NSIS}

A proposta NSIS é composta de duas camadas  (Fig.\ref{fig:cap_nsis_layers}): a
camada inferior, de transporte,
chamada \ac{GIST} ou \ac{NTLP}, e a camada superior, com
várias opções de protocolos de sinalização de aplicações, camada esta conhecida
como \ac{NSLP}. 

O protocolo \ac{NTLP} visa proporcionar funções que são comuns a todos
protocolos,
como por exemplo, a manutenção de estados ao longo dos roteadores de um caminho,
além de funções especiais como a capacidade de sinalizar a partir do transmissor
e do receptor de um fluxo (\textit{upstream} e \textit{downstream}).

Os protocolos de sinalização da aplicação se aplicam a diferentes propósitos:
gerenciamento de \textit{firewalls}, reserva de recursos (QoS NSLP) e até mesmo
a medição em redes.

\begin{figure}[!htpb]
 \centering
 \includegraphics[scale=.6]{figs/nsis_layers.png}
 \caption{Modelo Camada NSIS}
 \label{fig:cap_nsis_layers}
\end{figure}

Na sequência serão apresentados o protocolo de transporte de
sinalização \ac{GIST} e, com mais detalhes, o protocolo \ac{QoS NSLP},
responsável pela
sinalização de aplicação para \ac{QoS}, e foco deste trabalho.

\section{O Protocolo GIST}

A sinalização da aplicação requer um conjunto de regras de gerenciamento de
estado, bem como um protocolo de apoio para a troca de mensagens de dados ao
longo do caminho. Vários aspectos deste protocolo de apoio são comuns a todos ou
a um grande número de pedidos de sinalização da aplicação e, portanto, pode ser
desenvolvido como um protocolo comum. O GIST \cite{DRAFTGIST} é o protocolo de
transporte comum
a todos os protocolos de sinalização, em nível de aplicação.

Importante ressaltar a \ac{API} do \ac{GIST} é uma interface entre a camada de
transporte
da arquitetura \ac{TCP/IP} e a camada de sinalização de aplicação. As figuras
\ref{fig:cap_gist_layer} e \ref{fig:cap_gist_layer_osi} mostram isto.

\begin{figure}[!htpb]
 \centering
 \includegraphics[scale=.5]{figs/gist_layer.png}
 \caption{Modelo estrutura GIST \textit{(draft-ietf-nsis-ntlp-19)}}
 \label{fig:cap_gist_layer}
\end{figure}

\begin{figure}[!htpb]
 \centering
 \includegraphics[scale=.5]{figs/gist_layer_osi.png}
 \caption{Modelo camadas e posicionamento do GIST}
 \label{fig:cap_gist_layer_osi}
\end{figure}

O \ac{GIST} é projetado, portanto, para suportar diversos tipos de
aplicações de sinalização, pois sua funcionalidade é independente de uma
aplicação específica. O comportamento do GIST, em funcionamento, é transparente
para as camadas de
transporte e aplicação. Este funcionamento se torna adequado para evitar
interferências às mensagens de sinalização.

Uma das funções básicas do GIST é determinar o próximo nó a ser
visitado pelo protocolo de sinalização. Para o caso de sinalização sobre os
caminhos de dados, este próximo nó deve ser o nó visitado também pelo fluxo de
dados. É interessante observar que mudança de rotas podem causar
divergências temporárias entre o caminho de dados e o caminho da sinalização.

Quando o GIST recebe uma mensagem provinda da sinalização da aplicação, ele
examina uma informação chamada \ac{MRI},
fornecida junto com a mensagem. O \ac{MRI} identifica, na sua forma mais
simples, os
pontos iniciais e finais do fluxo. A mensagem, também informa se a sinalização
deve ser realizada em direção ou contra o fluxo. Uma vez determinado a direção e
o destino, o GIST tenta observar se já existe uma associação entre o próximo nó
e o nó atual. Esta associação, inerente ao modo \textit{C-Mode}, modo de
associação do nó GIST adjacente, é basicamente
uma conexão \ac{TCP} entre o nó atual e o próximo nó na rota da sinalização. Se
já
existe uma associação então ela pode ser utilizada para o transporte até o
próximo nó. Note que o próximo nó pode variar de acordo com o protocolo de
sinalização da aplicação.

No caso de não existir uma associação, então o GIST procede uma operação de
descoberta do próximo nó. Usando um pacote sonda UDP e usando a facilidade de
\textit{Router Alert} da camada IP, o GIST envia um pacote QUERY na direção do
destino
final do fluxo, respeitando se a sinalização é contra ou a favor do fluxo. Cada
roteador ao longo do caminho, processa o pacote, isto devido ao \textit{Router
Alert}
setado. O pacote é repassado para o GIST local que verifica se existe um
processo de sinalização de aplicação associado a mensagem (\ac{NSLPID},
identificador
do NSLP). 
Se existir, a entidade GIST responde a entidade GIST par que enviou o pacote
sonda através de uma mensagem RESPONSE. Neste momento, uma associação pode ser
estabelecida. O processo de relacionar uma associação (no caso do modo
\textit{C-mode})
com a dupla (\ac{NSLPID},\ac{MRI}) é o chamado armazenamento de estado no
roteador. Na
realidade, no NSIS existe também um identificador de sessão. Um ou mais fluxos
podem estar associados a uma sessão e, de fato, a identificação de um estado se
dá pela tríade (\ac{NSLPID},\ac{SID},\ac{MRI}), que define respectivamente, a
qual protocolo
NSLP, a qual sessão e a que fluxo, uma mensagem de sinalização de aplicação se
refere. O estado se apresenta então da forma da figura
\ref{fig:cap3_mod_msg_gist}.Nesta figura, a associação MA1 (associação 1) é
identificada através da da
tríade (NSLPID,SID,MRI). Além disto, a direção do fluxo é identificado por U
(\textit{upstream}).

\begin{figure}
\begin{verbatim}
+-------------------+-----------+
+ {MRI,SID,NSLPID}  | U ||  MA1 |
+-------------------------------+
\end{verbatim}
\caption{Modelo Mensagem GIST}
\label{fig:cap3_mod_msg_gist}
\end{figure} 

Existem alternativas às associações com \ac{TCP}, usando o protocolo UDP, mas
não
será discutido neste trabalho. Também existem alternativas ao uso do
\textit{Router
Alert} no processo de descoberta. Isto porque esta opção pode causar problemas
de segurança.

O GIST, em si, é um protocolo ponto a ponto. Isto significa que ao longo de um
caminho, um nó GIST só pode receber dados enviados pelos seus pares adjacentes,
ainda que estes dados não sejam destinados a ele. Quando o GIST recebe uma
mensagem de uma sinalização que não for destinado a ele, o GIST simplesmente
encaminha a mensagem para o seu próximo nó adjacente, que irá entregá-lo para a
camada GIST adequada. O transporte de uma mensagem de sinalização NSIS depende,
portanto, da capacidade de um nó de encontrar ou localizar corretamente seu
próximo nó adjacente.

\subsection{O problema de mudança de rotas}

O rearranjo topológico ou a mudança de rota pode impactar seriamente os estados
armazenados pelo GIST. Isto porque novos nós vizinhos podem aparecer, por
exemplo, mais próximos do que aqueles utilizados em uma determinada associação.

O GIST prevê alguns mecanismos para contornar este problema. Um deles, é o
envio periódico de pacotes sondas para encontrar os nós vizinhos e refazer
associações que estejam desatualizadas. Caso isto não ocorra, podem existir
situações inusitadas onde um nó aparentemente vizinho continua ser utilizado,
produzindo efeitos indesejáveis para os protocolos NSLPs. 

\section{O protocolo QoS NSLP}

O QoS NSLP (NSLP - \textit{NSIS Signaling Layer Protocol}) é um protocolo de QoS
da
camada de aplicação que atua na camada acima do GIST (figura
\ref{fig:cap_gist_layer}). Este protocolo estabelece e mantém estados nos
nós, ao longo do caminho de um fluxo de dados, com o objetivo de fornecer
informações para a manutenção de recursos para esse fluxo na rede. O seu modelo
de funcionamento consiste basicamente em receber os pacotes
de sinalização provindos do GIST, processar esta sinalização e repassar ao
gerenciador de recursos (ou devolver a sinalização ao GIST) para enviar a um
outro nó. Esta sinalização tem um caráter fim-a-fim, ou seja, a
sinalização é conduzida
desde um ponto inicial até um ponto final, passando por roteadores
intermediários.

Dentre as funcionalidades deste protocolo, podemos citar
\cite{DRAFTNSLP}:
\begin{itemize}
 \item Comportamento com \textit{soft-state}: uso de mensagens de
atualização de reserva periódicas. Caso nenhuma seja recebida dentro de um
intervalo pré-estabelecido a reserva é removida;
 \item Sinalização de fluxo unidirecional e bidirecional, ou seja, suporte a
mensagens de sinalização para fluxo em um só sentido e para dois fluxos em
sentido contrários;
 \item Capacidade de trabalhar em domínios \textit{DiffServ} usando recursos de
armazenamento mínimo de estados no núcleo dos domínios;
 \item Combinação de várias mensagens de reserva simultânea (\textit{Binding});
 \item Capacidade de detecção de mudança de rota  automaticamente, mantendo o
estado dos fluxos da rota anterior para a nova rota.
\end{itemize}

O QoS NSLP, invoca o GIST para efetuar tarefas de envio e recebimento de
mensagens através da API do GIST. O NSLP está na camada de aplicação, cuja
arquitetura pode ser mostrada na figura \ref{fig:cap_qos_nslp_layer}.

\begin{figure}[!htpb]
 \centering
 \includegraphics[scale=.6]{figs/qos_nslp_layer.png}
 \caption{Estrutura do NSLP (\textit{draft-ietf-nsis-qos-nslp-16})}
 \label{fig:cap_qos_nslp_layer}
\end{figure}

Onde 
\begin{itemize}
 \item \ac{QNE}: nó intermediário de apoio ao QoS NSLP;
 \item \ac{QNI}: o primeiro nó de uma sequência de QNEs que envia uma
requisição de reserva para uma sessão;
 \item \ac{QNR}: o último nó de uma sequência de QNEs que recebe uma
requisição de reserva para uma sessão.
\end{itemize}

As mensagens recebidas e capturadas pelo NSLP na entrada do nó são manipuladas
pelo GIST. Apenas as mensagens relacionadas com QoS são passadas para o QoS
NSLP. O GIST também pode disparar eventos ao QoS NSLP, como por exemplo,
indícios de mudança de rota. Neste último caso é feita nova sinalização, para a
nova rota, para manter a garantia dos recursos anteriormente estabelecidos.

O protocolo QoS NSLP trabalha utilizando poucas mensagens de comunicação, sendo
basicamente a mensagem de reserva. Mensagens QoS NSLP são enviadas a cada nó da
aplicação. Isto significa que um QNE considera seus pares adjacentes como fonte
de cada mensagem.

\subsubsection{Tipos de mensagens}
O protocolo QoS NSLP \cite{DRAFTNSLP} utiliza basicamente quatro tipos de
mensagens:

\begin{itemize}
 \item RESERVE: A mensagem de reserva é a única mensagem que manipula o estado
da reserva do QoS NSLP. É utilizada para criar, atualizar, modificar ou ainda
eliminar o estado na entidade;

 \item QUERY: Uma mensagem QUERY é utilizado para solicitar informações sobre o
caminho de dados sem fazer uma reserva. As informações obtidas a partir de uma
consulta pode ser utilizada no controle de admissão de um processo QNE (por
exemplo, no caso de medição baseada em admissão de controle). Esta mensagem não
altera as reservas de estado;

 \item RESPONSE: A mensagem RESPONSE é utilizada para fornecer informações
sobre o resultado de uma mensagem QoS NSLP recebida anteriormente. Isso inclui
a confirmação explícita a uma mensagem de reserva, a resposta a uma mensagem
QUERY ou uma mensagem de erro se o código QNE ou QNR for incapaz
de fornecer as informações solicitadas ou se a resposta é negativa. A mensagem
RESPONSE não pode realizar qualquer reserva de estado ou modificação de estado;

\item NOTIFY: são utilizadas para transmitir informações a um QNE. Difere da
mensagem RESPONSE na medida que as mensagens são enviadas de modo assíncrono e
não precisa de um determinado estado ou mensagem recebida anteriormente. A
informação de uma mensagem NOTIFY é normalmente relacionada às condições de
erro.
\end{itemize}

De forma geral, estas mensagens podem conter três tipos de objetos:
\begin{enumerate}
 \item \textit{Control Information} (Informações de Controle): transporta
informação para o QoS NSLP, tais como números de sequência, ou quando uma
reposta é necessária;
 \item \textit{QoS specifications} (QSPECs): O objeto \ac{QSPEC}
\cite{DRAFTQSPEC} transporta informação sobre os recursos necessários, os
recursos disponíveis, e outras informações exigidas pelo gerenciador de QoS do
domínio da rede;
 \item \textit{Objetos de Política}: Contêm dados utilizados
para autorizar a reserva de recursos.
\end{enumerate}


\subsection{Associações de Mensagens}
O protocolo QoS NSLP oferece suporte a associação de mensagens, a fim de
permitir expressar dependências entre diferentes mensagens. A associação de
mensagem pode indicar dependência unidirecional ou bidirecional entre duas
mensagens. Uma das mensagens da associação deve possuir um objeto de
identificação MSG\_ID \textit{Mensage Identifier}
(Identificador de mensagem) e a outra mensagem o objeto BOUND\_MSG\_ID
\textit{Bound Mensage Identifier}
(identificador de salto/fronteira).

A dependência unidirecional significa que apenas mensagens de RESERVE estão
vinculados um ao outro enquanto um dependência bidirecional significa que
existe dependência também para mensagens de RESPONSE. A associação de mensagem
pode ser utilizado para acelerar a sinalização, iniciando a sinalização de dois
intercâmbios simultaneamente e que são sincronizados depois usando mensagens de
identificações.

Por exemplo, a associação de mensagem pode ser utilizado para acelerar a
sinalização, onde,
se necessário, algumas trocas de mensagens podem ser iniciadas de modo
simultâneo e podem ser tratadas em paralelo até serem tratadas como uma sessão
única. Isto
é uma importante função do NSIS, que permite o tratamento em domínio por
agregado,
como pode ser visto na figura \ref{fig:cap3_mod_assoc_mensagem}.

\begin{figure}

\begin{verbatim}
QNE/QNI'     QNE'    QNR'/QNE      QNR
  +-------------------->|          |
  |  RESERVE |          |          |
  |          |          |          |
  | RESERVE' |          |          |
  |   (2)    |          |          |
  +=========>| RESERVE' |          |
  |          |   (2)    |          |
  |          +=========>| RESERVE  |
  |          |          |   (3)    |
  |          |          +--------->|
  |          | RESPONSE'|          |
  | RESPONSE'|<=========+          |
  |<=========+          |          |
  |          |          | RESPONSE |
  |          | RESPONSE |<---------+
  |<--------------------+          |
\end{verbatim}
 
\caption{Modelo associação de Mensagens}
\label{fig:cap3_mod_assoc_mensagem}
\end{figure} 

\subsection{Associação de Sessões e Reservas de Agregados}

Uma associação de sessão é definida como a relação entre diferentes sessões
de QoS NSLP (ou seja, sinalizando fluxos com diferentes SESSION\_ID
\textit{\eng{Session Identifier}}), conforme definido no GIST. A associação de
sessão indica uma relação entre duas ou mais sessões incluindo um
objeto BOUND\_SESSION\_ID. Uma sessão com um identificador SID\_A (associação
da sessão) pode expressar sua relação unidirecional de dependência a outra
sessão com SID\_B por BOUND\_SESSION\_ID incluindo um objeto contendo SID\_B nas
suas mensagens.

Uma mensagem pode incluir mais de um objeto BOUND\_SESSION\_ID. Isto pode
acontecer, por exemplo, em caso de agregação e reserva bi-direcional, onde uma
sessão fim-a-fim tem uma relação unidirecional de dependência com um agregado e,
ao mesmo tempo, este objeto tem uma relação unidirecional de dependência com
outra sessão utilizada para o caminho inverso.

Em alguns casos, por exemplo, em domínios \textit{DiffServ}, é desejável a
criação de reservas para um agregado, em vez de reserva por um fluxo, a fim de
reduzir o montante das reservas nos roteadores, bem como a redução do
processamento de mensagens de
sinalização. Contudo, o QoS NSLP não especifica quantas reservas devem ser
combinadas em um agregado, mas fornece sinalização para tal.

A diferença fundamental nesta abordagem é que a reserva precisa de duas seções
diferentes, uma que descreve todo o tráfego transportado no agregado (por
exemplo, um DSCP no caso de \textit{DiffServ}) e a outra por fluxo simples, em
cada roteador do caminho.

\subsection{Funcionamento com Estado Reduzido ou sem Estado}
	
Este exemplo usa um modelo diferente de sinalização dentro de um domínio. Esta
funcionalidade evita o armazenamento do estado nos nós do interior do domínio.
Como resultado, os nós do interior só armazenam o QSPEC relacionados com
reservas direcionadas.

A sinalização neste modelo permite que mensagens sinalizem de ponta a ponta em
um domínio, de modo transparente, enquanto a sinalização sem estado passa por
todos os nós, do domínio, anunciando o fluxo necessário. Ao final, as mensagens
são centralizadas e a resposta é enviada, cujo modelo pode ser melhor observado
na figura \ref{fig:cap3_mod_msg_estado_reduzido}.

\begin{figure}
\begin{verbatim}
           QNE             QNE             QNE            QNE
         Entrada        interior        interior         Saída
            |               |               |              |
    RESERVE |               |               |              |
   -------->| RESERVE       |               |              |
            +--------------------------------------------->|
            | RESERVE'      |               |              |
            +-------------->|               |              |
            |               | RESERVE'      |              |
            |               +-------------->|              |
            |               |               | RESERVE'     |
            |               |               +------------->|
            |               |               |  RESPONSE'   |
            |<---------------------------------------------+
            |               |               |              | RESERVE
            |               |               |              +-------->
            |               |               |              | RESPONSE
            |               |               |              |<--------
            |               |               |     RESPONSE |
            |<---------------------------------------------+
    RESPONSE|               |               |              |
   <--------|               |               |              |
\end{verbatim}

\caption{Modelo de mensagem em estado reduzido ou sem estado}
\label{fig:cap3_mod_msg_estado_reduzido}
\end{figure} 


\subsection{Re-roteamento}
\label{cap3_reroteamento}

O QoS NSLP se adapta a mudanças na rota do caminho de dados. Isto pressupõe a
capacidade de detectar eventos de reencaminhamento, criar uma reserva de QoS
sobre o novo caminho e, opcionalmente, derrubar as reservas existentes sobre o
antigo caminho.

Para a camada de aplicação NSLP, o reencaminhamento pode ser realizado de duas
maneiras. Pode vir através de uma notificação de mudança de rota do GIST, ou a
partir de informações vistas através de mensagens do NSLP. Neste último caso, o
nó QoS NSLP é capaz de detectar mudanças nos nós adjacentes através do \ac{SII}.
Quando uma mensagem com uma reserva existente
SESSION\_ID e um diferente \ac{SII} é recebida, o QNE conhece que seu nó
\textit{upstream} ou \textit{downstream} foi alterado.

A nova reserva, sobre o novo caminho, acontece quando uma mensagem RESERVE chega
ao QNE onde a antiga e a nova rota são divergentes. Se a QoS NSLP suspeita que
tenha ocorrido mudança de rota, em seguida, uma mensagem de RESERVE com o QSPEC
é enviado. Aliado a isto, a mensagem de atualização de estado será identificada
com um erro pelo QNE que não tem a reserva instalada, no novo caminho.

A rápida recuperação na camada NSLP, portanto, requer atualização em períodos
curtos e detecção antes que a próxima mensagem de RESERVE chegue. Esta
informação, no entanto, só é possível de se obter na camada IP ou através do
acompanhamento dos estados do GIST, isto através da relação entre o GIST e o
NSLP.

Após a reserva sobre o novo caminho, o nó pode querer derrubar a reserva sobre o
antigo caminho antes do tempo normal do protocolo \textit{soft-state} ou do tempo
de
expiração da mensagem. Esta funcionalidade é suportada pelo acompanhamento dos
antigos \ac{SII} ao longo do caminho na API do GIST. 

Se o antigo caminho é no sentido do fluxo (\textit{downstream}), o QNE pode
enviar um mensagem de RESERVE usando o antigo \textit{SII-Handle}. Se o antigo
caminho é no sentido \textit{upstream}, o QNE pode enviar um NOTIFY com o código
para alteração de rota \textit{Route Change}. Este é transmitido até que
encontre um nó QNE que possa emitir uma mensagem RESERVE para o fluxo correspondente.

\subsection{Interações com o Gist}

A QoS NSLP usa o GIST frequentemente para a entrega de suas mensagens. As
mensagens são transmitidas a partir do NSLP para o GIST através de uma API,
conforme figura \ref{fig:cap_gist_layer_osi}, que identifica as informações como
sessão de fluxo, direção, IP e porta. Na recepção, o GIST fornece as
mesmas informações para a QoS NSLP.

A QoS NSLP mantém as mensagens e seus estados por sessão. A sessão é
identificado por um SESSION\_ID. O SESSION\_ID é o
principal índice de NSLP para armazenar o estado e deve ser único ao longo de um
caminho da rede. Este valor é posteriormente utilizado pelo GIST e as aplicações
do NSLP para se referir a uma sessão.

O GIST deve suportar as mensagens e operações do NSLP, sem interferir em seu
processamento. Ao receber uma mensagem o GIST só envia esta para a camada de
aplicação se for direcionado para o nó em questão, caso contrário, o GIST pode
encaminhar para o próximo nó.

\subsection{Considerações sobre QSPEC}

O QSPEC tem por objetivo prover uma linguagem comum para ser utilizada por
gerenciadores de QoS podendo ser transportado por mensagens RESERVE, QUERY,
RESPONSE e NOTIFY.

Um nó QNI inicia uma sinalização e adiciona um objeto QSPEC contendo os
parâmetros desejados de QoS. Os parâmetros do QSPEC devem ser interpretados por
todos os nós do interior do domínio QNE marcados para gerenciamento de recurso.

Sua estrutura é simples, e fornece uma descrição do tráfego para o qual os
recursos são reservados. O cabeçalho do QSPEC pode ser visto na mensagem de
sinalização do NSIS, figura \ref{fig:cap3_exemplo_sinalizacao_obj_qspec}, 
conforme fragmento do retorno do protocolo, retirado dos cenários montados:

\begin{figure}

\begin{verbatim}
\+ Object Type       : InfoSpec
\++ InfoSpec         : 0x01 0x02 0x00 0x00
\+ Object Type       : Qspec
\++ V:Id:M_Seq:OC:l  : 0:0:0:3:20
\+++ QSPEC object    : QoS Desired
\+++ Object type     : Tmod1, length:4
\+++ Object type     : ExcessTreatment, length:1
\+++ QSPEC object    : QoS Available
\+++ Object type     : Tmod1, length:4
\+++ QSPEC object    : Minimum QoS
\+++ Object type     : Tmod1, length:4
(...)
\+++ QSPEC object    : QoS Model (QOSM)
(...)
\+++ QSPEC object    : QoS Reserved
\end{verbatim}
\caption{Exemplo de sinalização com objetos QSPEC}
\label{fig:cap3_exemplo_sinalizacao_obj_qspec}
\end{figure} 

Pode-se descrever os objetos de QSPEC e sua estrutura conforme mostrado na figura \ref{fig:cap3_obj_estrutura_qspec}:

\begin{figure}

\begin{verbatim}
   +---------------------------------------+
   |            QSPEC Objects              |
   +---------------------------------------+

   \________________ ______________________/
                    V
   +----------+----------+---------+-------+
   |QoS Desir.|QoS Avail.|QoS Rsrv.|Min QoS|
   +----------+----------+---------+-------+

   \____ ____/\___ _____/\___ ____/\__ ___/
        V         V          V        V

   +-------------+...     +-------------+...
   |QSPEC Para. 1|        |QSPEC Para. n|
   +-------------+...     +-------------+...

\end{verbatim}
\caption{Objetos da estrutura QSPEC}
\label{fig:cap3_obj_estrutura_qspec}
\end{figure} 

\begin{itemize}
 \item QSPEC: QSPEC é o objeto de QoS NSLP contendo todas as informações
específicas de QoS.
 \item QoS \textit{Desired}: Objeto QSPEC que contém parâmetros descrevendo os
parâmetros de QoS desejado para os quais o QNI recebeu tráfego.
 \item QoS \textit{Available}: Objeto QSPEC que contém parâmetros descrevendo os
recursos disponíveis. Eles são usados para recolher informação junto de uma reserva.
 \item QoS \textit{Reserved}: Objeto QSPEC que contém parâmetros descrevendo os
recursos reservados e os respectivos parâmetros de QoS.
 \item QoS \textit{Model} (QOSM): Um método com o modelo de QoS desejado pelos
domínios.
\item QSPEC \textit{parameter}: Parâmetros utilizados em uma especificação,
como latência, modelo de tráfego (TMOD) e tratamento.
 \item QSPEC \textit{Object}: Principais parâmetros de um QSPEC estabelecido
tanto na entrada como na saída de um gerenciador de QoS.
 \item QSPEC \textit{Type}: Identifica um determinado QOSM utilizado no QSPEC.
\end{itemize}


\section{Outros Protocolos NSLP}

Na seção anterior foi visto com mais detalhes o protocolo de sinalização, no
nível de aplicação, QoS NSLP, voltado a sinalização de qualidade de serviço.
Entretanto, já existem propostas na IETF de outros protocolos NSLP voltados ao
controle de firewalls e de medição em redes. 

O NSIS natfw é um exemplo de cliente NAT/\textit{Firewall} NSLP cuja finalidade
é
limitada principalmente ao desenvolvimento de testes. A API destina-se a ser
incluído em aplicações para falar diretamente com NAT/\textit{Firewall} NSLP
para
configurar dispositivos NAT ou \textit{firewall} ao longo de um caminho. Ele
pode ser
acionado através do GIST na camada de transporte.

O NAT/\textit{Firewall} NSLP pode ser acionado para enviar mensagens de vários
tipos,
dependendo do modelo escolhido, uma série de tipos específicos de opções pode
ser definido, como \textit{proxy}, simulação de processos, bloqueio ou permissão
de
fluxos de pacotes e regras de policiamento.

O NSIS apresenta também um modelo de gerenciamento por fluxo, o \ac{RMF} que
gerencia o nó alocando recursos conforme sinalizado. O
\ac{RMF} utiliza ferramentas do linux para controle de fluxo, como o \textit{tc}
e o \textit{iptables},
o que o torna simples e extremamente eficiente.

O \ac{RMF} trabalha em separado do NSIS, contudo o RMF recebe as informações do
daemon NSIS que verifica a existência de especificação do fluxo. Este
especificação será lida somente pelo RMF, o nsis trata somente da sinalização.